Conversation
|
Diff from mypy_primer, showing the effect of this PR on open source code: openlibrary (https://github.com/internetarchive/openlibrary)
- openlibrary/solr/data_provider.py: note: In member "preload_metadata" of class "DataProvider":
- openlibrary/solr/data_provider.py:214: error: Argument 1 to "_get_lite_metadata" of "DataProvider" has incompatible type "tuple[tuple[str, ...], ...]"; expected "Sequence[str]" [arg-type]
- openlibrary/solr/data_provider.py:224: error: Argument 1 to "_get_lite_metadata_direct" of "DataProvider" has incompatible type "tuple[str, ...]"; expected "str" [arg-type]
|
|
Why does this need to be fixed here and not in typeshed? |
|
@JelleZijlstra IIRC typeshed doesn't want to have explicit protocol bases. This is why we used to have the original patch in the first place. TBH I don't remember why we can't fix this in mypy (but at least this will add some perf penalty, since protocols are a bit slower than nominal subclasses). |
|
Oh, wait, now there is an actual inconsistency in the type of |
|
Oh, sorry, but the inconsistency is caused by our patch, all looks good then, ignore my previous comment. |
ilevkivskyi
left a comment
ilevkivskyi
left a comment
There was a problem hiding this comment.
Yeah, I checked discussion on typeshed, they are aware this will be a breaking change, but the decision was that this is fine, since this is a relatively new feature (Python 3.12), and this will allow more precise item types.
3 participants
Fixes #20697
Changed the base type of
itertools.batchedfromIterator[tuple[_T_co, ...]]toIterator[_T_co]in the stub and patch files so that mypy no longer reports an error due to a mismatched return type of__next__.